Summary

upb_Message_GetOrPromoteExtension() matches a message's unknown fields by field number only. A same-number unknown carrying a non-delimited wire type (varint or fixed) was still captured and handed to upb_MiniTable_ParseUnknownMessage(), which re-decodes the bytes as a length-delimited sub-message.

ParseUnknownMessage() reads a tag and then a varint length from those bytes:

data = upb_WireReader_ReadTag(data, &tag, NULL);
data = upb_WireReader_ReadVarint(data, &message_len, NULL);
upb_Decode(data, message_len, ...);

For a varint field such as 08 01 (field 1, value 1), the value 1 is consumed as message_len and data is left one byte past the end of the captured field, so upb_Decode() reads out of bounds.

This adds a kUpb_WireType_Delimited check to the match. A same-number field with any other wire type now falls through to the existing _upb_WireReader_SkipValue() branch and is left as an unknown, exactly like an unrelated field.

Tests

Added PromoteIgnoresWrongWireType: ModelExtension1.model_ext encoded with a varint wire type now returns kUpb_GetExtension_NotPresent instead of being promoted.

Also verified with a standalone -fsanitize=address,undefined build: the wrong-wire input no longer faults and returns kUpb_GetExtension_NotPresent, and a correctly length-delimited empty-message extension still promotes (kUpb_GetExtension_Ok, non-null message).

Follow-up

The legacy PromoteUnknownToMessage / ...Array / ...Map paths reach the same ParseUnknownMessage() sink via the public upb_Message_FindUnknown(). I left that helper untouched to avoid changing its semantics; the same guard can be applied there in a follow-up if you'd prefer.